Hi,

Here are the review comments for the data model. Some of the comments are from an older review and I have repeated them for completeness.

Regards,
Srivatsa.

An overall comment is that the document needs to describe in text those elements that are new and should not re-define elements that were previously described in RFC 4575. This needs to be changed throughout the document. Also, sections of the text that describe XML elements should be very explicit about whether this is optional or not.  Furthermore, you should be very explicit about which elements have a state attribute defined now (this is missing in various places, like <media> and <controls> and <from-mixer>, <to-mixer>). The RELAX-NG schema is also missing this in one location.

Section 3

"   The data model defined in this document is the result of extending
   the data model defined in RFC 4575 [1] with new elements, which carry
   information such as non-SIP URIs or floor-control-related parameters."

[SS] Suggest rewording -- "The data model specified here includes extensions to the schema defined in RFC 4575. Examples of such extensions include scheduling elements, media control elements, floor control elements, some conference policy elements and addition of localization extensions to text elements."

[SS] Also, a reminder that the root namespace used in this document is "urn:ietf:params:xml:ns:conference-schema" as opposed to what RFC 4575 uses ("urn:ietf:params:xml:ns:conference-info"). Needs fixing. Also, suggest renaming the extension namespace (where the new XML elements are defined in this document) to " urn:ietf:params:xml:ns:xcon-conference-info" instead of "urn:ietf:params:xml:ns:conference-schema". Or at least something to indicate that this is something completely different from conference-info.

[SS] Suggest removing "This data model can be used by conference servers providing different   types of basic conferences."

Section 3.1

[SS] This section has text that is already covered in RFC 4575. Why is it needed?

Section 3.2

[SS] It is not clear how the definitions are extensible as defined. Also, it is not clear what a conferencing client should do when the conferencing system does not support a certain role. Also, how does the client learn that a conferencing client does not support that role? It may be useful to have text that redirects some of these answers to an external inter-op Spec(T) in-order to clearly delineate areas of the document that were intentionally left open.

"If no
   roles are defined for an entity, they SHOULD by default be a
   "participant" but local policy MAY define an alternative."

[SS] A better way to put this is "If no roles are defined for an entity or the conferencing system cannot grant the requested role, it SHOULD default to the role of a "participant" but local policy MAY define an alternative."

Section 3.2.1

[SS] Not clear if <floor> is optional or not.

Section 3.2.2

[SS] Eliminate this section; should be in the conference protocol document, if at all anywhere.

Section 4

[SS] Not clear again, if a conferencing system MUST implement/support XCON-URI's.

Section 4.1.2 and Section 4.1.3

[SS] Same comment as in Chicago -- not convinced of the use of <H.323> and <PSTN-ISDN> elements.

Section 4.1.5

[SS] I am repeating some of my comments from an earlier email regarding mixing mode and mix level. This is an inter-op nightmare, unless specified normatively. Is this still required even after the <video-layout> element was added?

[SS] Mixing mode is a very specific implementation detail of mixing. What does it mean to define a mixing-mode for every stream -- is this mode applied to the incoming stream to or the outgoing ones from the mixer? And why would a conference participant (organizer or moderator or attendee) be interested in choosing one over the other?

[SS] Also, for layouts, an enumeration of specific layout string identifiers with localized description strings for each layout will be more useful than just an integer aka mix-level. Note that this can be clubbed or rather replaced with a <control> element for layouts. Also, a specific mixer output stream may only support one layout. A client capable of receiving multiple streams may receive more than one stream, each with different layouts or multiple streams each with the same layout. For example, a mixer may output two streams each capable of only a single layout (fixed layouts by the mixer) -- the main video with active speaker and another stream (or multiple streams) of a proprietary mix (like enhanced video from a conference room).

Section 4.1.5.1.1, 4.1.5.1.2, 4.1.5.1.3, 4.1.5.1.4

[SS] Overall comment: Suggest rewording by reusing some of the text from the media usages draft or pointing to it.

"In the
   <controls> element the schema is extensible, hence new control types
   can be added in the future.  Similarly, controls that apply to a
   specific user would appear under the <users>/<user>/<endpoint>
   element.  So moderator controls that affect all media output would go
   under the <available-media> element."

[SS] Remove the sentence starting with "Similarly" in the above paragraph. Define it separately under <users> definition.

"If this control is not specified, access to the control is not
   available to the client and media SHOULD NOT be transported for the
   associated media stream."

[SS] Avoid repeating, if possible. Just point out similarities in the controls.

"The 'video-layout' control is used in conjunction with a video stream
   to specify how the video streams (participants) are viewed by each
   participant."

[SS] This section needs to specify how this is extensible. Also, specify whether a conferencing system should implement these? Or are they completely optional?

Section 4.2

"The <uris> child element contains a
   sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>."

[SS] Remove text.

Section 3.7.1

" The
   'method' attribute is a list with the following values: "dial-in",
   "dial-out, and "refer".  The value "dial-in" is used by the focus to
   determine who can join the conference.  Value "refer" is used by the
   focus to determine the resources that the focus needs to "refer to"
   the conference."

[SS] Unclear why a conferencing system would want to let the conference organizer describe "how" a conference participant joins? This is up-to local implementation. If a specific participant has a value of 'dial-in' but is later dialed-out, what does that mean?

4.5.2.1.  <from-mixer>, <to-mixer>

[SS] Suggest rewording section.

   "This section specifies controls that apply to a user's media stream being sent from the mixer to the participants endpoint or to the mixer from the participants endpoint. The <to-mixer> element details properties associated with the streams sent to the mixer (from the participant).
   The <from-mixer> element details properties associated with the streams sent from the
   mixer (to the participant).  Both of these elements have the attribute 'name'.  "

4.5.3.  <sidebars-by-ref> and
4.5.4.  <sidebars-by-val>

[SS] These sections are not required (defined in RFC 4575) remove them unless there are some specific extensions defined here.

[SS] As an end disclaimer, I have not checked the RELAX-NG schema or the examples.


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon